-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update dispute game contracts for oplabs-devnet-0 and op-sepolia #789
base: main
Are you sure you want to change the base?
Conversation
4bb2067
to
49ce28c
Compare
0b14019
to
e2de554
Compare
e2de554
to
87a4db3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe ethereum-optimism/superchain-ops#421 will change some addresses for op-sepolia again.
@Inphi is this still relevant? |
This is still relevant as the dispute game addresses are out of date on op networks. I'll rebase the work on top of the latest changes in a couple days. |
Updates the dispute game contracts for the oplabs sepolia devnet and op-sepolia.
This also adds
PermissionedDelayedWETH
, andMIPS64
to the chain addresses.Context for MIPS64 Superchain Upgrades
The
CANNON
andPERMISSIONED_CANNON
game implementations will be replaced with new implementations that use the MIPS64 VM. MIPS64 is effectively the oldMIPS
VM. The MIPS64.sol contract semver precedes the MIPS.sol semver and so a new MIPS64 config value is added to prevent the backwards semver check from failing in CI.This is awkward as it's no longer clear which VM implementation is used by a chain from looking at the superchain-registry. This awkwardness is temporary as once the superchain upgrades to MIPS64, we can remove the
MIPS64
config field by replacing theMIPS
config value with a deployed MIPS64 contract address.The op-program prestate releases are agnostic to type of VM used to generate the prestate. That is, given a absolute prestate hash in the release registry, it's either a MIPS or MIPS64 generated prestate but not both. This creates a problem during FP validation checks as the op-sepolia MIPS64 upgrade was based on the
op-program/v1.4.0-rc.3
release. And the prestate of that release already exists in the registry as a MIPS prestate.To workaround this issue, FP validation is tweaked to avoid checking the absolute prestate on testnets that use MIPS64. This workaround can be removed once OPCM manages upgrades.